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1 

2 NETWORK-BASED SYSTEM EMPLOYING AN APPLICATION SERVER THAT 

3 PROVIDES INTEGRATED MULTIPARTY INVOICE PROCESSING 
4 

5 BACKGROUND OF THE INVENTION 
6 

7 1 . Field of the Invention 

8 This invention relates broadly to electronic-based commerce systems and 

9 methods. More particularly, this invention relates to electronic-based invoicing systems 
1 0 and methods. 

11 

12 2. State of the Art 

13 In a typical commercial transaction between a seller of goods and/or services and 

14 a buyer of such goods and services, the seller creates an invoice for such goods and 

1 5 services that is presented to the buyer for payment by the buyer. Traditionally, the 

1 6 invoice is created by the seller, printed out in paper form and mailed to buyer. Upon 

1 7 receipt, the invoice is typically routed through an approval process at the buyer (requiring 

1 8 review by one or more individuals or departments within the buyer's organization). The 

1 9 invoice may be disputed by the buyer (requiring adjustment to the invoice, and the 

20 process begins again) or may be approved by the buyer. Once payment is authorized, the 

21 buyer issues a payment instrument (such as a check) and sends the payment instrument to 

22 the seller, seller's bank, or other entity of the seller for payment processing. This entire 

23 process may take several weeks and requires separate accounting records to be kept and 

24 harmonized at both the seller (accounts receivable) and the buyer (accounts payable). 
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2 With the advent of the Internet (and other distributed network technologies), 

3 electronic-commerce systems have been developed that streamline the traditional 

4 invoicing process by enabling electronic presentment of invoices as well as electronic 

5 payment of such invoices. An example of such a system is described in U.S. Patent 

6 Application Publication US 2003/0004874, published Jan 2, 2003. In this system, a biller 

7 system loads a batch invoice file into the system via an invoice loader. The invoices of 

8 the batch invoice file are loaded into a database. An application server enables a biller 

9 system user operating a web browser to interact with the application server over the 

1 0 Internet. Such biller-side interaction enables querying the invoices stored in the database, 

1 1 displaying the details of a selected invoice, sending messages (such as text messages and 

1 2 e-mail messages) to the payer associated with an invoice, adjusting and allowing an 

1 3 invoice, and performing other actions associated with the stored invoices. In addition, the 

1 4 application server enables a payer system user operating a web browser to interact with 

1 5 the application server over the Internet. Such payer-side interaction enables querying the 

1 6 invoices stored in the database, displaying the details of a selected invoice, reviewing and 

1 7 approving part or all of an invoice, initiating payment of an invoice, and performing other 

1 8 actions associated with the stored invoices. Such a system enables efficient presentment 

1 9 of invoices to the payer (buyer) and efficient payment of such invoices; however, the 

20 system requires a separate and distinct application executed by the biller (seller) for 

21 managing the information from which the invoices are derived and for creating invoices. 

22 This increases the total cost of the solution. 
23 
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1 

2 Thus, there remains a need in the art for an improved electronic-commerce system 

3 that provides for seller-side processing that enables maintenance of billing information 

4 and creation of invoices derived from such billing information as well as buyer-side 

5 processing that enables efficient approval and payment of invoices, to thereby provide for 

6 a lower cost electronic-based invoicing solution. 
7 



8 SUMMARY OF THE INVENTION 

9 

10 It is therefore an object of the invention to provide an improved electronic- 

1 1 commerce system that provides seller-side processing that enables maintenance of billing 

1 2 information and creation of invoices derived from such billing information as well as 

1 3 buyer-side processing that enables efficient approval and payment of invoices. 
14 

15 It is another object of the invention to provide such an improved electronic- 



1 6 commerce system utilizing an application server framework that provides for network- 

1 7 based seller-side access as well as network-based buyer-side access. 
18 



19 It is a further object of the invention to provide such an improved electronic- 

20 commerce system wherein seller-side access and buyer-side access occur in real time 

21 over network connections to an application server framework. 
22 
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1 In accord with these objects, which will be discussed in detail below, a system 

2 (and corresponding method) operates in conjunction with the sale of goods and/or 

3 services provided by a first entity to a second entity. The system (and corresponding 

4 method) provides for electronic presentment of bills and invoices related to such 

5 sales/transactions. It includes a first means for authenticating at least one first-entity- 

6 class user and second means for authenticating at least one second-entity-class user. An 

7 application server includes a first application component that interacts in real-time over a 

8 network with an authenticated first-entity-class user to enter, create, maintain, and store 

9 biUing information and related invoices pertaining to at least one second entity. A second 

1 0 application component interacts in real-time over the network with an authenticated 

1 1 second-entity-class user to access portions of the billing information and related invoices 

1 2 pertaining to the authenticated second-entity-class user. The first application component 

1 3 and the second application component operate in conjunction with data security logic to 

1 4 selectively control first-entity class user access and second-entity -class user access to the 

1 5 billing information and related invoices maintained by the system. 
16 

17 It will be appreciated that electronic-based invoicing systems in accordance with 

1 8 the present invention enables efficient approval and payment of invoices. Moreover, the 

1 9 highly integrated architecture of such systems provides for a lower cost invoicing 

20 solution to both sellers and buyers and thus opens up new markets for such advanced 

21 invoicing functionality. 
22 
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1 According to the preferred embodiment of the invention, the first application 

2 component enables access to particular billing information by at least one authenticated 

3 second-entity-class user in response to finalization of the particular billing information^ 

4 wherein the finalization is accomplished by interaction with an authenticated first-entity- 

5 class user. Moreover, the first application component and second application component 

6 are preferably adapted such that the particular billing information cannot be added to an 

7 invoice until approved by an authenticated second-entity-class usen In addition, the first 

8 application component preferably enables access to particular invoice information by at 

9 least one authenticated second-entity-class user in response to posting of the particular 

10 invoice information, which is accomplished by interaction over the network with an 

1 1 authenticated first-entity-class user. 
12 

1 3 Additional objects and advantages of the invention will become apparent to those 

1 4 skilled in the art upon reference to the detailed description taken in conjunction with the 

1 5 provided figures. 
16 
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2 

3 Fig. 1 is a block diagram of an electronic bill presentment and invoice processing 

4 system in accordance with the present invention; 
5 

6 Fig. 2 is a block diagram of the functionality provided by the subscriber- 

7 administrator logic of the application server of Fig. 1 in accordance with the present 

8 invention. 
9 

10 Figs. 3 A - 3E are pictorial illustrations of exemplary graphical user interfaces that 

1 1 may be displayed at the browser-based subscriber-administrator system as part of the 

1 2 processing provided by the subscriber-administrator logic of Fig, 2 in accordance with 

13 the present invention. 
14 

1 5 Figs. 4A - 41 are pictorial illustrations of exemplary graphical user interfaces (or 

1 6 reporting view(s)) that may be displayed at the browser-based subscriber-administrator 

1 7 system as part of the processing provided by the subscriber-administrator logic of Fig. 2 

18 in accordance with the present invention. 
19 
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1 Fig. 5 is a block diagram of the functionality provided by the subscriber-staff 

2 logic of the application server of Fig. 1 in accordance with the present invention. 
3 

4 Fig. 6 is a block diagram of the functionality provided by the client-administrator 

5 logic of the application server of Fig. 1 in accordance with the present invention. 
6 

7 Figs. 7A - 7D are pictorial illustrations of exemplary graphical user interfaces (or 



8 reporting view(s)) that may be displayed at the browser-based client-administrator system 

9 as part of the processing provided by the client-administrator logic of Fig. 6 in 
1 0 accordance with the present invention. 

11 



1 2 Fig. 8 is a block diagram of the functionality provided by the client-staff logic of 

1 3 the application server of Fig. 1 in accordance with the present invention. 
14 

1 5 Fig. 9 is a schematic diagram that illustrates various states of a billing entry 

1 6 through the invoicing process carried out by the invoicing system of Fig. 1 in accordance 

1 7 with the present invention. 
18 

1 9 Fig. 10 is a schematic diagram that illustrates various states of an invoice through 

20 the invoicing process carried out by the invoicing system of Fig. 1 in accordance with the 

2 1 present invention. 
22 
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1 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

2 

3 Turning now to Fig. 1, there is shown the architecture of an electronic invoicing 

4 system 1 in accordance with the present invention. There are two classes (denoted 

5 "Subscribers" and "Clients") of users of the system. One or more Subscribers, which 

6 belong to a Subscriber entity, access the system over a network (such as the Internet) to 

7 enter/create, update, store and view billing information (in electronic form) that is related 

8 to goods and/or services provided to one or more Clients. One or more Subscribers also 

9 access the system over the network to electronically present such billing information to 

1 0 the appropriate Client for review and approval by the Client. One or more Clients, which 

1 1 belong to a Client entity, access the system to review and approve (or disapprove) the 

1 2 bills electronically-presented thereto by the Subscriber(s). In this manner, the system 

1 3 enables centralized creation and management of the billing information and invoices by 

14 the Subscriber(s) as well as network-based collaboration that enables efficient 

1 5 presentation, approval, and possibly payment of invoices by the Client(s). 
16 

1 7 The Subscriber(s) of the system have a hierarchical logical organization including 

1 8 one or more Subscriber Administrators and zero or more Subscriber Staff Members. The 

1 9 Subscriber Administrator(s) has full access to the billing information maintained by the 

20 system for the particular Subscriber, and can create and maintain certain user- 

21 configurable aspects of the system for the particular Subscriber. The Subscriber Staff 

22 Member(s) are created and maintained by the Subscriber Administrator(s) and have 

23 limited access to the billing information maintained by the system for the particular 
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1 Subscriber. For example, in the preferred embodiment of the present invention, the 

2 Subscriber Staff Member can only view and update billing information that was 

3 originally created by the Subscriber Staff Member. 
4 

5 Similarly, the client(s) of the system have a hierarchical logical organization 

6 including one or more Client Administrators and zero or more Client Staff Members. 

7 The Client Administrator(s) has limited access (for example, access granted only upon 

8 submission by the Subscriber to the Client for approval as described below) to the billing 

9 information maintained by the system for the particular Client, and can create and 

1 0 maintain certain user-configurable aspects of the system for the particular Client. The 

1 1 Client Staff Member(s) are created and maintained by the Client Administrator(s) and 

1 2 have limited access to the billing information maintained by the system for the particular 

1 3 Client. For example, in the preferred embodiment of the present invention, the Client 

14 Staff Member can only view and update billing information that was submitted by the 

1 5 Subscriber to the Client for approval and that is associated with a location (e.g., 

1 6 Department, Division, Branch Office, etc.) of the Client submitted by the Subscriber to 

1 7 the Client for approval originally created by the Subscriber Staff Member. 
18 

19 As shown in Fig. 1, the Subscriber Administrator(s) and Subscriber Staff 

20 (commonly referred to herein as Subscriber Administrator/Staff) utilize a web browser 

21 executing on a computing device 3 to connect to a web server 5 over the network 7 (e.g., 

22 Internet). Similarly, the Client Administrator(s) and Client Staff (commonly referred to 

23 herein as Subscriber Administrator/Staff) utilize a web browser executing on a computing 
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1 device 9 to connect to the web server 5 over the network 7. Preferably, the browser- 

2 based interaction between the computing devices 3, 5 and the web server 5 occur over 

3 TCP/IP sessions established therebetween over which are communicated HTML-based 

4 (and possibly XML-based) documents and commands as well as other messages, 

5 commands and data. The web server 5 enables login and authentication of Subscriber 

6 Administrator/Staff via interaction with the Subscriber system 3 as well as login and 

7 authentication of Client Administrator/Staff via interaction with the Client system 9. 

8 Such login and authentication can utilize password-based authentication, operating 

9 system-based authentication (e.g., NTLM or Kerberos); services-based authentication 

1 0 (e.g., Microsoft Passport authentication), certificate-based authentication, or any other 

1 1 authentication scheme. Once a user session has been authorized (whether it be a 

1 2 Subscriber Administrator/Staff session or Client Administrator/Staff session), the web 

1 3 server 5 communicates with an Application Server 1 1 to build dynaniic web page(s) 

1 4 based on data supplied by the Application Server 1 1 and serve the dynamic web page(s) 

15 to the Subscriber Administrator/Staff web browser (or the Client Administrator/Staff web 

1 6 browser) as requested, and forward (and/or transform) data supplied by the Subscriber 

1 7 Administrator/Staff web browser (or Subscriber Administrator/Staff web browse) to tiie 

1 8 Application Server 1 1 as needed. Preferably, the web server 5 is located in a 

1 9 "demilitarized zone" (DMZ) provided with a firewall router 13. In, this configuration, 

20 the firewall/router 13 enables authorized communication between the web server 5 and 

21 the Application Server 1 1 (typically utilizing a secure socket layer (SSL) interface or an 

22 IPSec interface), while blocking unauthorized communication requests to the Application 

23 Server 1 L In addition, the web server 5 preferably utilizes style sheets to build the 
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1 HTML documents (and XML documents) for presentment to the Subscriber 

2 Administrator/Staff web browser (or Subscriber Administrator/Staff web browse). The 

3 web server 5 may be realized by commercially available HTTP servers, such as the 

4 Apache Web Server, Microsoft Internet Information Server, and Sun ONE Web Server. 
5 

6 The Application Server 1 1 includes a Subscriber Application Component 15, a 

7 Client Application Component 17, Adnfiinistration/Configuration Logic 19, Data Security 

8 Logic 21, a Database 23 storing bills and invoices. Presentation Services 25, Network 

9 Security Services 27, and possibly Messaging Logic 29. The 

1 0 Administration/Configuration Logic 19 provides for system management and 

1 1 configuration of the Application Server 11. The Presentation Services 25 are facilities 

1 2 that enable delivering dynamic content to client browsers. Preferably, the Presentation 

1 3 Services 25 support Active Server Pages, JavaServer pages, server-side scripting such as 

14 Perl, CGI, PL/SQL scripting, etc. The Network Security Services 27 provides facilities 

1 5 that enable maintaining network security (such as SSL-based or IPSec-based encryption 

1 6 and authentication facilities). Preferably, the Application Server 1 1 is realized by a 

1 7 commercially-available software framework, such as the WebLogic Platform 

1 8 commercially available from BEA Systems of San Jose, CA, the Websphere Application 

1 9 Server commercially available from IBM, Windows Server Systems conmiercially 

20 available from Microsoft Corporation of Redmond, WA, or the SUN ONE Application 

21 Server commercially available from Sun Microsystems of Santa Clara, CA. 
22 



.11- 



KYE-001 

1 The Subscriber Application component 15, works in conjunction with the 

2 Presentation Services 25 and other components of the Application Server 1 1, to provide 

3 dynamic content to the web server 5 for delivery to the browser-based Subscriber 

4 Administrator/Staff system 3. The Subscriber Application component 15 also encodes 

5 business logic that represents the Subscriber-side part of the invoicing process (e.g., the 

6 creation, update, storage, and finalization of invoices on the part of the Subscriber 

7 Administrator/Staff). It also updates state information that represents the status of 

8 invoices in conjunction with this invoicing process. 
9 

1 0 The Client Application component 17, works in conjunction with the Presentation 

1 1 Services 25 and other components of the Application Server 1 1, to provide dynamic 

1 2 content to the web server 5 for delivery to the browser-based Client Administrator/Staff 

13 system 9. The Client Application component 17 also encodes business logic that 

1 4 represents the Client-side part of the invoicing process (e.g., the review, 

1 5 approval/rejection, and payment of invoices on the part of the Client 

1 6 Administrator/Staff). It also updates state information that represents the status of 

1 7 invoices in conjunction with this invoicing process. 
18 

1 9 The billing information and invoices created and updated during the invoicing 

20 process is stored in the database 23. The database 23 can be realized by files stored by 

21 the application server 17. Alternatively, the database 23 can be realized by a relational 

22 database that is part of the application server (as shown), or coupled thereto by an 

23 appropriate database connector interface. 
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2 Data Security Logic 21 provides facilities that enable controUed-access to the 

3 information stored in the database 23. In the invoicing system of the present invention, 

4 the Data Security Logic 21 provides user-level access control to the billing information 

5 and invoices that are created and maintained by the Subscriber-side part of the invoicing 

6 process. For example, it is preferred that such information remain inaccessible to the 

7 Client Administrator/Staff until an invoice is finalized for submission to the Client entity. 

8 In addition, it is preferred that the Application Server 1 1 include Messaging Logic 29 that 

9 provides facilities that support messaging between Subscriber Administrator/Staff and 

10 Client Administrator/Staff. The messaging can be in the form of text messages, instant 

1 1 messages, or e-mail messages. 
12 

1 3 The processing functionality provided by the Subscriber Application Component 

14 15 is preferably logically partitioned into two parts: Subscriber- Administrator logic 3 1 

1 5 and Subscriber-Staff logic 33. The Subscriber- Administrator logic 3 1 interacts with a 

1 6 browser-based Subscriber- Administrator user to perform various functions as part of the 

1 7 Subscriber-side invoice processing. Examples of such functions are described below 

1 8 with respect to Figs. 2 through 41. The Subscriber-Staff logic 33 interacts with a 

1 9 browser-based Subscriber-Staff user to perform various functions as part of the 

20 Subscriber-side invoice processing. Examples of such functions are described below 

21 with respect to Fig. 5. 
22 
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1 Similarly, the processing functionality provided by the Client Application 

2 Component 17 is preferably logically partitioned into two parts: Client-Administrator 

3 logic 35 and Client-Staff logic 37. The Client-Administrator logic 35 interacts with a 

4 browser-based Client- Administrator user to perform various functions as part of the 

5 Client-side invoice processing. Examples of such functions are described below with 

6 respect to Figs. 6 through 7D. The Client-Staff logic 37 interacts with a browser-based 

7 Client-Staff user to perform various functions as part of the Client-side invoice 

8 processing. Examples of such functions are described below with respect to Fig. 8. 
9 

1 0 Turning now to Fig. 2, there is shown a high-level schematic representation of 

1 1 exemplary functions provided by the Subscriber- Administrator logic 31. Such functions 

1 2 include a block 201 that interacts with a browser-based Subscriber- Administrator user to 

1 3 create a Client entity. An example of the graphical user interface that may be displayed 

14 at the browser-based Subscriber- Administrator system 3 as part of block 201 is shown in 

1 5 Fig. 3 A, It enables the Subscriber- Administrator user to create a Client by entering the 

1 6 Client name (labeled "Customer Name"), Client Administrator login name and password, 

1 7 and Contact Name and address and contact information, and Location name and address 

1 8 and contact information. Once the Client is set up, the Subscriber- Administrator user 

1 9 turns over the Client- Administrator login name and password to the Client. The Client- 

20 Administrator now becomes the Administrator for the Client account. If the Client is 

21 currently using the system, the block 201 enables the Subscriber- Administrator to search 

22 for the Client and assign the Client to his account. 
23 
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1 The Subscriber- Administrator logic 3 1 also preferably includes a block 203 that 

2 enables the Subscriber- Administrator user to create (or change) a contract (or project) 

3 that pertains to a specific Client. An example of the graphical user interface that may be 

4 displayed at the browser-based Subscriber- Administrator system 3 as part of block 203 is 

5 shown in Fig. 3B. It enables the Subscriber-Administrator user to create a 

6 contract/project by defining a contract name and time period (e.g., start date and end 

7 date). The contract/project may have recurring periods (of one or more types) and may 

8 be associated with only one location of the specific Client. The project/contract can also 

9 specify rules and conditions that dictate how billing is carried out for the contract period. 

1 0 For example, it can specify that all billing associated with this project/contract is pre- 

1 1 approved. In this case, the billing information does not require approval by the specific 

1 2 Client before it is accumulated into an invoice for subnnission to the specific Client. In 

1 3 another example, it can specify a number of units (such as man-hours) that are billed free- 

1 4 of-charge during the contract period, or a number of cutoff units (such as man-hours) and 

1 5 associated billing rate adjustment. In this case, in the event that the number of units 

1 6 billed in the contract period exceeds the number of cutoff units, the difference and billing 

1 7 rate adjustment is used to determine the bill. In another example, the contract/project can 

18 be setup to automatically generate invoices for specific Clients, or a Client and Location 

1 9 combination. Preferably, only Subscriber-Administrator users are allowed create and 

20 maintain contracts and projects. 
21 

22 The Subscriber- Administrator logic 31 also preferably includes a block 205 that 

23 enables the Subscriber- Administrator user to create (or change) billing rates associated 
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1 with particular services (labeled "task) provided by the Subscriber entity to one or more 

2 Client entities. An example of the graphical user interface that may be displayed at the 

3 browser-based Subscriber- Administrator system 3 as part of block 205 is shown in Fig. 

4 3C. It enables the Subscriber- Administrator user to define a billing rate for a given task. 

5 The billing rate can be selectively applied to all Subscriber-staff members (or a particular 

6 Subscriber-Staff member), to all clients (or a particular client), and/or to a particular 

7 client location. The selections allow the same Subscriber-Staff member to be billed out 

8 at varying rates for the same task for different Clients. 
9 

1 0 The Subscriber- Administrator logic 3 1 also preferably includes a block 207 that 

1 1 enables the Subscriber-Administrator user to define a Subscriber-Staff member. An 

1 2 example of the graphical user interface that may be displayed at the browser-based 

1 3 Subscriber- Administrator system 3 as part of block 207 is shown in Fig. 3D. It enables 

1 4 the Subscriber- Administrator user to create a Subscriber-Staff member by entering the 

1 5 Subscriber-Staff name, Login name and password, other miscellaneous information (e.g., 

1 6 social security number, gender, salary, etc), and selecting one or more Clients that are 

1 7 affiliated with the Subscriber-Staff member, 
18 

1 9 The Subscriber- Administrator logic 31 also preferably includes a block 209 that 

20 enables the Subscriber-Administrator user to assign (and create) billing services (referred 

21 to as "tasks") associated with particular Client. An example of the graphical user 

22 interface that may be displayed at the browser-based Subscriber-Administrator system 3 

23 as part of block 209 is shown in Fig. 3E. It enables the Subscriber- Administrator user to 
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1 selectively assign one or more tasks to a particular Client (or all Clients), or to possibly a 

2 particular Client location. The task is a short description of the services provided by the 

3 Subscriber entity. Preferably, the billing tasks associated with a particular Client are used 

4 only in conjunction with Time Billing of the particular Client. 
5 

6 The Subscriber- Administrator logic 31 also preferably includes blocks 211 and 

7 213 that enable the Subscriber- Administrator to create (and maintain) Accounts Payable 

8 information and Accounts Receivable Information as well as a General Ledger, 

9 respectively. Such functionality is well known in the electronic-based accounting arts. 

1 0 The integrated Accounts Payable functionality of block 213 enables the Subscriber- 

1 1 Administrator to easily calculate payment for the Subscriber-Staff member(s). Within 

1 2 this functionality, disbursements to the Subscriber-Staff can be easily generated and 

1 3 managed throughout the system. For example, profit and loss reports can be generated to 

14 analyze the billed vs. compensation for any Subscriber-Staff member(s). Such profit and 

1 5 loss reports is derived from the same data that is entered for billing by the Subscriber- 

1 6 Staff member(s) (see block 501 of Fig. 5 and accompanying description). The 

1 7 Subscriber-Staff also has access to disbursements made to them (see block 503 of Fig. 5 

1 8 and accompanying description), and checks are generated using existing staff 

1 9 information, reducing duplicate data entry. Note that Accounts Payable information and 

20 Accounts Receivable information is not available to Client users (e.g., Client- 

21 Administrators and/or Client-Staff). 
22 
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1 The Subscriber- Administrator logic 3 1 also preferably includes a block 215 that 

2 enables the Subscriber-Administrator user to enter (or update) time-based billing 

3 information for a particular Client. An example of the graphical user interface that may 

4 be displayed at the browser-based Subscriber- Administrator system 3 as part of block 215 

5 is shown in Fig. 4A. It enables the Subscriber- Administrator user to enter time-based 

6 billing information for a specific Client and Location, It also enables the Subscriber- 

7 Administrator user to select a contract/project of the particular Client and (and possibly a 

8 task assigned to the particular Client and contract/project). The description of the 

9 services provided (labeled "billing description") can be selected from a pull-down menu 

1 0 as shown and then edited. The user selects from a pop-up calendar (or manually enters) 

1 1 the date that the services are provided. Total units are automatically calculated based on 

1 2 the Start and End time entered by the user, unless the user enters a number in the Total. 

1 3 In this case, the Start and End Times are ignored. Free Units are subtracted from the 

1 4 Total Units. The billing information entered (or updated) in block 215 is stored in the 

1 5 database 23 for subsequent access therefrom. 
16 

1 7 The Subscriber- Administrator logic 3 1 also preferably includes blocks 217 and 

18 219 that enable the Subscriber- Administrator user to enter one-time billing information or 

1 9 other miscellaneous billing information (such as expenses or other non-time related 

20 billing information) for a particular Client, respectively. An example of the graphical 

21 user interface that may be displayed at the browser-based Subscriber-Administrator 

22 system 3 as part of block 217 is shown in Fig. 4B. It enables the Subscriber- 

23 Administrator user to enter billing information for a specific Client and Location. It also 
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1 enables the Subscriber-Administrator user to select a contract/project of the particular 

2 client. The user enters the date that the goods or services are provided, a description of 

3 such goods or services to be billed, and cost information (e.g., number of units, unit cost, 

4 tax rate) for such goods or services. A similar graphical user interface may be displayed 

5 at the browser-based Subscriber-Administrator system 3 as part of block 219. The billing 

6 information entered (or updated) in blocks 217 and 219 is stored in the database 23 for 

7 subsequent access therefrom. 
8 

9 The Subscriber- Administrator logic 31 also preferably includes a block 221 that 

1 0 enables the Subscriber-Administrator user to process and administer billing information 

1 1 stored in the database 23. An example of a graphical user interface that may be displayed 

12 at the browser-based Subscriber- Administrator system 3 as part of block 221 is shown in 

1 3 Fig. 4C. It enables a Subscriber- Administrator user to edit/update a billing entry stored in 

1 4 the database 23, and approve the billing entry for submission to the Client. By selecting 

15 the Submit action text, the block 221 cooperates with the Data Security Logic 21 to 

1 6 enable one or more Client- Administrator users (and possibly one or more Client-Staff 

1 7 users) to access the billing entry stored in the database 23 for subsequent access 

1 8 therefrom. A more detailed description of the role-based access controls for a billing 

1 9 entry during the invoicing process is set forth below with respect to Fig. 9. 
20 

21 The Subscriber- Administrator logic 31 also preferably includes a block 223 that 

22 enables the Subscriber- Administrator user to create (and process) invoices that are 

23 derived from the billing information stored in the database 23. An example of the 
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1 graphical user interfaces that may be displayed at the browser-based Subscriber- 

2 Administrator system 3 as part of block 223 are shown in Figs. 4D, 4E and 4F. The 

3 graphical user interface of Fig. 4D enables the Subscriber-Administrator user to create an 

4 invoice for a specific Client and Location and user-selected date range. The user enters 

5 the date for the invoice and possibly other information (e.g., invoice type, due date, 

6 account that will be paid, purchase order code, etc). When the user selects the create 

7 button, the functionality of block 221 queries the database 23 to identify the billing 

8 information stored therein that pertains to the specific Client and Location and falls 

9 within the user-selected date range (and which has been approved by the Client and has 

1 0 not yet been incorporated into an invoice), adds such billing information to an invoice, 

1 1 and displays information for the invoice (such as the invoice date, Client, dollar amount 

1 2 for the invoice, billing descriptions and dates for the billing information from which the 

1 3 invoice is derived, etc). The graphical user interface of Fig. 4E enables the Subscriber- 

1 4 Administrator user to finalize (sometimes referred to herein as "post" or "posting") an 

1 5 invoice for submission to the Client. By selecting the Post action text, the block 223 

1 6 cooperates with the Data Security Logic 21 to enable one or more Client- Administrator 

1 7 users (and possibly one or more Client-Staff users) to access the invoice entry stored in 

1 8 the database 23 for subsequent access therefrom. The graphical user interface of Fig. 4F 

1 9 enables the Subscriber- Administrator user to cancel the post of an invoice for submission 

20 to the Client. By selecting the Cancel action text, the block 223 cooperates with the Data 

21 Security Logic 21 to disable Client- Administrator users (and Client-Staff users) access to 

22 the invoice entry stored in the database 23. In this manner, the invoice entry reverts back 

23 to being hidden from the Client- Administrator users (and Client-Staff users) of the 
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1 system. A more detailed description of the role-based access controls of an invoice 

2 during the invoicing process is set forth below with respect to Fig. 10. Preferably, an 

3 invoice is identified with a date when it is OPEN (i.e., it has not been finalized/posted). 

4 After finalization, a number is assigned to the invoice and that is the number that is 

5 referenced throughout the life of the invoice. 
6 

7 The Subscriber- Administrator logic 31 also preferably includes a block 225 that 

8 enables the Subscriber-Administrator user to generate (and print) reports related to billing 

9 entries and invoices stored in the database 23. An example of the graphical user 

1 0 interfaces that may be displayed at the browser-based Subscriber- Administrator system 3 

11 as part of block 225 are shown in Figs. 4G, 4H and 41. The graphical user interface of 

1 2 Fig. 4G enables the Subscriber- Administrator user to specify a Client (or Client- 

1 3 Location) and possibly specify a date range and/or other criteria. Upon selection of the 

14 view report button, the billing entry(ies) and/or invoices stored in the database 23 that 

1 5 match the user-specified criteria are displayed as a report. An example of a report of 

1 6 billing information is shown in Fig. 4H. An example of a report for invoices is shown in 

1 7 Fig. 41, which enables the Subscriber- Administrator user to edit, update and process an 

1 8 invoice by selecting the Invoice number action text. It also enables the Subscriber- 

1 9 Administrator user to apply and reconcile payment of the invoices by entering the 

20 appropriate information. 
21 

22 Turning now to Fig. 5, there is shown a high-level schematic representation of 

23 exemplary functions provided by the Subscriber-Staff logic 33. Such functions include a 
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1 block 50 1 that interacts with a browser-based Subscriber-Staff user to enter (or update) 

2 billing information for a particular Client. Such billing information can be time-based 

3 billing information, one time billing information, or other miscellaneous billing 

4 information. The billing information entered (or updated) in block 501 is stored in the 

5 database 23 for subsequent access. Graphical user interfaces similar to those described 

6 above with respect to Figs. 4A, 4B and 4C may be displayed at the browser-based 

7 Subscriber-Staff system 3 as part of block 50 1 . Preferably, billing entries created by the 

8 Subscriber-Staff user can be readily updated by the Subscriber-Staff user until it is 

9 submitted by the Subscriber-Staff user. Upon submission, a billing entry can be accessed 

1 0 and viewed by the Subscriber-Staff user, but can be edited only by a Subscriber- 

1 1 Administrator user. The Subscriber- Administrator user then approves the billing entry for 

1 2 submission to the Client as described above with respect to Fig. 4C. 
13 

1 4 The Subscriber-staff logic 33 also preferably includes block 503 that enables the 

1 5 Subscriber-Staff user to generate (and print) reports related to billing entries created (or 

1 6 updated) by the specific Subscriber-Staff user and stored in the database 23. Graphical 

1 7 user interfaces similar to those described above with respect to Figs. 4G and 4H may be 

1 8 displayed at the browser-based Subscriber-Staff system 3 as part of block 503. In this 

1 9 case, the displayed billing entries pertain to the Subscriber-staff user. Moreover, the 

20 functionality of block 503 preferably enables the Subscriber-Staff user to access 

21 disbursements made to the user as part of the Accounts Payable functionality of block 

22 211 (described above with respect to Fig. 2). 
23 
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1 In the event that a given Subscriber-staff user performs services for multiple 

2 Client entities of the system, it is preferred that the authentication facilities (e.g., login 

3 name and password) for the Subscriber-staff user provide access to the billing data for the 

4 multiple Clients. This minimizes the complexity of the authentication process of the 

5 Subscriber-staff user (for example, the user need not remember and/or enter separate 

6 passwords for each Client). 
7 

8 The Subscriber-Staff logic 33 may also provide a number of unique features that 

9 are afforded to the Subscriber-Staff members, including generating a report of earnings 

10 for a time period (which is preferably specified by user input) and any checks that were 

1 1 generated through the system. 
12 

1 3 Turning now to Fig. 6, there is shown a high-level schematic representation of 

1 4 exemplary functions provided by the Client- Administrator logic 35. Such functions 

1 5 include a block 601 that interacts with a browser-based Client- Administrator user to 

1 6 create (or update) a Client-Staff member for the Client entity to whom the Client- 

1 7 Administrator belongs. A graphical user interface similar to that described above with 

1 8 respect to Fig. 3D may be displayed at the browser-based Client- Administrator system 9 

19 as part of block 601 is shown in Fig. 3D. It enables the Client- Administrator user to 

20 create (or update) a Client-Staff member by entering the Client-Staff name, Login name 

21 and password, other miscellaneous information (e.g., social security number, gender, 

22 salary, etc), and selecting one or more Subscribers that are affiliated with the Client-Staff 

23 member. 
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1 

2 The Client-Administrator logic 35 also preferably includes a block 603 that 

3 enables the Client-Administrator user to create (or update) one or more locations (e.g., 

4 Department, Division, Branch Office, etc.) of the Client entity to which the Client- 

5 Administrator logic belongs. Preferably, in block 603, the Client-Administrator user 

6 enters (or updates) the name, address, and other miscellaneous information (such as 

7 location contact information) for the location. In addition, in block 603, the Client- 

8 Administrator user preferably can assign one or more Client-Staff members to one or 

9 more locations. 
10 

1 1 The Client- Administrator logic 35 also preferably includes a block 605 that 

1 2 enables the Client- Administrator user to create (or change) a contract (or project) for the 

1 3 Client entity to whom the Client- Administrator belongs. A graphical user interface 

1 4 similar to that described above with respect to Fig. 3B may be displayed at the browser- 

1 5 based Client- Administrator system 9 as part of block 605. It enables the Client- 

1 6 Administrator user to create a contract/project by defining a contract name and time 

1 7 period (e.g., start date and end date). The contract/project may have recurring periods (of 

1 8 one or more types) and may be associated with one or more locations of the Client. The 

1 9 project/contract can also specify rules and conditions that dictate how billing is carried 

20 out for the contract period. For example, it can specify that all billing associated with this 

21 project/contract is pre-approved. In this case, the billing information does not required 

22 approval by the Client before it is accumulated into an invoice for submission to the 

23 Client. In another example, the contract/project can be set up to automatically generate 
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1 invoices for specific Clients, or a Client and Location combination. Preferably, only 

2 Client-Administrator users are allowed create and maintain contracts and projects. 
3 

4 The Client-Administrator logic 35 also preferably includes a block 607 that 

5 enables the Client-Administrator user to process and administer billing information stored 

6 in the database 23 that pertain to the specific Client to whom the Client-Administrator 

7 belongs. An example of a graphical user interface that may be displayed at the browser- 

8 based Client- Administrator system 9 as part of block 607 is shown in Fig. 7 A. It enables 

9 a Client-Administrator user to review and approve billing entries stored in the database 

10 23 that pertain to a specific Subscriber entity. The specific Subscriber entity is associated 

1 1 with the Client entity to whom the Client-Adniinistrator belongs. Approval is 

12 accomplished by selecting the Approval All action text for a given billing entry. 

1 3 Preferably, such approval enables the billing entry to be added to an invoice by the 

1 4 specific Subscriber as described below with respect to Fig. 9. In the processing of block 

1 5 607, billing entries that are "OPEN" and have yet to be "FINALIZED" by the specific 

1 6 Subscriber are not accessible to any Client- Administrator user (or any Client-Staff user). 

1 7 Thus, only the billing entries that have been "FINALIZED" by the specific Subscriber are 

1 8 accessible to the Client- Administrator user for review and approval. 
19 

20 The Client- Administrator logic 35 also preferably includes a block 609 that 

21 enables the Client- Administrator user to process and administer invoices that are derived 

22 from the billing information stored in the database 23. An example of a graphical user 

23 interface that may be displayed at the browser-based Client- Administrator system 9 as 
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1 part of block 609 is shown in Fig. 7B. It enables the Client- Administrator user to review 

2 the invoices for one or more specific Subscribers (and possibly for other user selected 

3 criteria such as a particular Subscriber, Client-Location, user-selected date range etc). 

4 The specific Subscriber(s) are associated with the Client entity to whom the Client- 

5 Administrator belongs. When the user selects the invoice identifier action text, the 

6 details of the invoice are displayed for review by the Client-Administrator user. 

7 Preferably, block 609 also enables the Client-Administrator user to initiate payment (e.g., 

8 full payment or partial payment) for a particular invoice (or provide an indication of such 

9 payment), which changes the state of the invoice. This state change is accessible to the 

1 0 Subscriber that subniitted the invoice as described below with respect to Fig. 10. In the 

1 1 processing of block 609, invoices that are "OPEN" and have yet to be "COMMITTED" 

12 by the specific Subscriber(s) of the Client are not accessible to any Client- Administrator 

1 3 user (or any Client-Staff user). Thus, only the invoices that have been "COMMITTED" 

14 by the specific Subscriber(s) are accessible to the Client- Administrator user for review 

1 5 and administration. In block 609, payment of one or more invoices may be accomplished 

16 by a payment transaction electronically submitted to the bank of the Subscriber or an 

17 Automated Clearing House, by an automated credit card (or debit card) transaction, or by 

1 8 other electronic payment settlements means. Alternatively, the payment of one or more 

1 9 invoices may be accomplished by traditional payment mechanisms, such as mailing a 

20 paper check to the specific Subscribers. 
21 

22 The Client- Administrator logic 35 also preferably includes a block 611 that 

23 enables the Client- Administrator user to generate (and print) reports related to billing 



-26- 



. KYE-001 

1 entries and invoices stored in the database 23. A graphical user interface similar to that 

2 shown in Fig. 4G may be displayed at the browser-based Client-Administrator system 9 

3 as part of block 611, which enables the Client- Administrator user to specify a Subscriber 

4 (and possibly Client-Location) and possibly specify a date range and/or other criteria. 

5 Upon selection of the view report button, the billing entry(ies) and/or invoices stored in 

6 the database 23 that match the user-specified criteria are displayed as a report. An 

7 example of a report of billing information is shown in Fig. 7C. An example of a report 

8 for invoices is shown in Fig. 7D. 
9 

10 Turning now to Fig. 8, there is shown a high-level schematic representation of 

1 1 exemplary functions provided by the Client-Staff logic 37. Such functions include a 

1 2 block 801 that interacts with a browser-based Client-Staff user at Client system 9 to 

1 3 generate (and print) reports related to billing entries created (or updated) by the specific 

1 4 Client-Staff user and stored in the database 23. Graphical user interfaces similar to those 

1 5 described above with respect to Figs. 4G and 4H may be displayed at the browser-based 

1 6 Client-Staff system 9 as part of block 801. In this case, the displayed billing entries 

1 7 pertain to the Client-Staff user. 
18 

1 9 Turning now to Fig. 9, there is shown a schematic diagram that illustrates various 

20 states of a billing entry through the invoicing process carried out by the invoicing system 

21 of Fig. 1 in accordance with the present invention. In each state, a set of security 

22 classifications (denoted for access granted, and "N" for access not granted) dictate 

23 access to the billing entry by Subscriber- Administrator users (denoted "S-A"), 
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1 Subscriber-Staff users (denoted "S-S"), Client- Administrator users (denoted "C-A"), and 

2 Client-Staff users (denoted ''C-S'') in the state. 
3 

4 When a billing entry is created (or updated), it has an "OPEN" state. In the 

5 "OPEN" state, Subscriber-Administrator users and those Subscriber-Staff users that 

6 created (or added to) the billing entry can access the billing entry. However, the Client- 

7 Administrator users and Client-Staff users cannot access the billing entry. 
8 

9 When a Subscriber-Administrator user approves the billing entry, the state of the 

1 0 billing entry transitions to the "FINALIZED" state. In the "FINALIZED" state, 

1 1 Subscriber-Administrator users and those Subscriber-Staff users that created (or added to) 

12 the billing entry can access the billing entry. In addition, the Client- Administrator users 

1 3 and those Client-Staff users designated by a Client- Administrator can also access the bill. 

1 4 The application server 1 1 may cooperate with messaging logic 29 to notify a designated 

1 5 Client- Administrator of the submission of the billing entry by the Subscriber entity to the 

1 6 Client for approval by the client. 
17 

1 8 When a Client- Administrator user (or possibly a designated Client-Staff user) 

1 9 approves a "FINALIZED" billing entry, the state of the billing entry transitions to the 

20 "APPROVED BY CLIENT" state. In the "APPROVED BY CLIENT" state, Subscriber- 

21 Administrator users and those Subscriber-Staff users that created (or added to) the billing 

22 entry can access the billing entry. In addition, the Client-Administrator users and those 

23 Client-Staff users designated by a Client- Administrator can also access the billing entry. 
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1 The application server 1 1 may cooperate with messaging logic 29 to notify a designated 

2 Subscriber-Administrator of the approval of the billing entry by the Client. Note that in 

3 some cases (for example, where the billing entry is associated with a contract/project for 

4 which automatic invoicing has been selected)^ the state of the billing entry automatically 

5 transitions from the "FINALIZED" state to the "APPROVED BY CLIENT" state 

6 without Client approval. Preferably, in the "APPROVED BY CLIENT" state, the billing 

7 information in the billing entry can be added to an invoice; while, in the other states, the 

8 billing information in the billing entry cannot be added to an invoice. 
9 

1 0 When a Client- Administrator user (or possibly a designated Client-Staff user) 

1 1 rejects a FINALIZED" billing entry, the state of the billing entry transitions to the 

1 2 "REJECTED BY CLIENT" state. In the "REJECTED BY CLIENT" state, Subscriber- 

1 3 Administrator users and those Subscriber-Staff users that created (or added to) the billing 

1 4 entry can access the billing entry. In addition, the Client- Administrator users and those 

1 5 Client-Staff users designated by a Client- Administrator can also access the bill. The 

1 6 application server 1 1 may cooperate with messaging logic 29 to notify a designated 

1 7 Subscriber- Administrator of the rejection of the billing entry by the Client. The 

1 8 Subscriber entity is then free to re-open the billing entry for adjustment, clarification, or 

1 9 resubmission. In this case, the state of the billing entry reverts back to the "OPEN" state 

20 and the process begins again. 
21 

22 Turning now to Fig. 10, there is shown a schematic diagram that illustrates 

23 various states of an invoice through the invoicing process carried out by the invoicing 
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1 system of Fig. 1 in accordance with the present invention. In each state, a set of security 

2 classifications (denoted ''V for access granted, and "N'' for access not granted) dictate 

3 access to the billing entry by Subscriber-Administrator users (denoted "S-A"), 

4 Subscriber-Staff users (denoted "S-S"), Client-Administrator users (denoted "C-A'O, and 

5 Client-Staff users (denoted "C-S") in the state. 
6 

7 When an invoice is created (or updated), it has an "OPEN" state. In the "OPEN" 

8 state, Subscriber- Administrator users can access the invoice. However, the Subscriber- 

9 Staff users, Client- Adniinistrator users and Client-Staff users cannot access the invoice. 
10 

1 1 When a Subscriber- Administrator user posts the invoice, the state of the billing 

12 entry transitions to the "COMMITTED" state. In the "COMMITTED" state, Subscriber- 

1 3 Administrator users can access the invoice, while the Subscriber-Staff users cannot 

14 access the invoice. In addition, the Client- Administrator users and those Client-Staff 

1 5 users designated by a Client- Administrator can also access the invoice. The application 

1 6 server 1 1 may cooperate with messaging logic 29 to notify a designated Client- 

1 7 Administrator of the posting of the invoice by the Subscriber entity to the Client for 

1 8 payment by the Client. 
19 

20 When a Client- Administrator user (or possibly a designated Client-Staff user) 

21 initiates full-payment (or provides an indication of such full-payment) for a 

22 "COMMITTED" invoice, the state of the invoice transitions to the "PAID-IN-FULL" 

23 state. In the "PAID-IN-FULL" state, Subscriber-Administrator users can access the 
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1 invoice, while the Subscriber-Staff users cannot access the invoice. In addition, the 

2 Client-Administrator users and those Client-Staff users designated by a Client- 

3 Administrator can also access the invoice. The application server 1 1 may cooperate with 

4 messaging logic 29 to notify a designated Subscriber- Administrator of the full-payment 

5 of the invoice (or indication thereof) by the Client. 
6 

7 When a Client- Administrator user (or possibly a designated Client-Staff user) 

8 initiates partial-payment (or provides an indication of such partial-payment) for a 

9 "COMMITTED" invoice, the state of the invoice transitions to the "PAID-IN-PART" 

10 state. In the "PAID-IN-PART" state. Subscriber- Administrator users can access the 

1 1 invoice, while the Subscriber-Staff users cannot access the invoice. In addition, the 

1 2 Client- Administrator users and those Client-Staff users designated by a Client- 

1 3 Administrator can also access the invoice. The application server 1 1 may cooperate with 

1 4 messaging logic 29 to notify a designated Subscriber- Administrator of the partial- 

1 5 payment of the invoice (or indication thereof) by the Client. The Subscriber entity is then 

16 free to re-open the invoice for adjustment, clarification, or resubmission. In this case, the 

1 7 state of the invoice reverts back to the "OPEN" state and the process begins again. 
18 

1 9 Advantageously, the electronic-based invoicing systems of the present invention 

20 provides for seller-side processing that enables real-time entry and maintenance of billing 

21 information and creation of invoices derived from such billing information as well as 

22 buyer-side processing that enables efficient approval and payment of invoices. This 
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1 highly integrated architecture provide for a lower cost invoicing solution to both sellers 

2 and buyers and thus opens up new markets for such advanced invoicing functionality. 
3 

4 There have been described and illustrated herein several embodiments of systems 

5 and methods for carrying out electronic bill presentment and invoicing. While particular 

6 embodiments of the invention have been described, it is not intended that the invention be 

7 limited thereto, as it is intended that the invention be as broad in scope as the art will 

8 allow and that the specification be read likewise. Thus, while particular invoicing 

9 processes has been disclosed, it will be appreciated that other invoicing processes can be 

1 0 realized as well. For example, and not by way of limitation, the roles of the subscriber 

1 1 users and client users of the system can be readily adapted to acconunodate variations in 

12 the invoicing process carried out by the system. Such role changes result in adaptations 

13 to the logical components of the application server that carry out the invoicing process. 

1 4 Also, while preferred system architectures, graphical user interfaces, and underlying 

1 5 functional logic has been disclosed, it will be understood that modifications thereto can 

16 be similarly used. It will therefore be appreciated by those skilled in the art that yet other 

1 7 modifications could be made to the provided invention without deviating from its spirit 

1 8 and scope as claimed. 
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